Power management and control is an important and evolving part of computing technology. Greater demand for computing devices with more functionality and smaller size increases the need for an efficient power management and configuration system. For instance, many computing systems, particularly in smaller, laptop computers, have moved toward hot-pluggable components so that they may be dynamically removed to conserve power and weight when not needed. ACPI (Advanced Configuration and Power Interface) is an emerging industry specification that defines a flexible and extensible interface for power and configuration management. The interface enables and supports power management through improved hardware and operating system coordination. ACPI allows the operating system to control the power states of many hardware components, and to pass information to and from some hardware components, such as the temperature of a thermal sensor or the power remaining in a battery. It should be noted that a computer system may include both hardware components that are designed to interact with an ACPI system and some that are not.
Stated generally, to interact with the ACPI system, hardware components provide a platform-independent description of themselves (termed “ACPI tables”) to an ACPI portion of the computer's operating system. At boot time, the ACPI subsystem builds a namespace that describes each of the several ACPI-compliant hardware devices by loading the several ACPI tables. Each ACPI table may include methods that allow the ACPI subsystem or other program modules to interact with the ACPI-compliant hardware devices.
More specifically, the ACPI specification defines two types of ACPI tables that are pertinent to the present discussion: a Differentiated System Description Table (DSDT) and a Secondary System Description Table (SSDT). The DSDT is part of a fixed system description loaded at system boot and it cannot be unloaded. SSDTs are description tables that may be loaded after system boot. There may be multiple SSDTs but there is only one DSDT. The theory is that an OEM can provide base system support in one table (the DSDT) and add smaller system options on an as needed basis in other tables (the SSDTs).
The ACPI specification provides for an Unload function to unload SSDTs that may be loaded, however, existing ACPI implementations have not implemented the Unload function for several reasons. For instance, there has not been a real need to use SSDTs in addition to the DSDT. Creating and loading a DSDT to describe the typical computing system has been sufficient because most computing systems simply don't have components which are routinely removed or that require an ACPI description to be removed from the namespace. In addition, difficult synchronization issues have acted to dissuade ACPI system developers from implementing an unload capability.
Moreover, removing entries from the ACPI namespace creates collision issues with entries that would subsequently be loaded. For mostly that reason, in the few instances where computing components are commonly removed from a computing system (such as undocking a laptop computer), the ACPI objects are simply left in the namespace. If another ACPI table is subsequently loaded in the namespace and has the same name or is configured to support the same device, a collision would occur. Until now, namespace collisions have been avoided by simply loading multiple ACPI descriptions for each alternative type of hardware device that may be present and then not unloading them. The number of alternative hardware devices has, until recently, been small enough that the DSDT can be loaded with each alternative hardware device without a need for SSDTs. Alternatively, the number of SSDTs that may be loaded is small enough that there has not been a need to unload them.